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Method and System for Link Management 

BACKGROUND OF THE INVENTION 

RELATED APPUC ATIONS 

Hus application claims prioiity from U.S. Patent Application serial number 09/593,150, filed 
5 June 14, 2000, incorporated herein by reference. 

FIELD OF THE INVENTION 

The present invention consists of a method and system for managing links between digital 
assets. More particularly, it concems a method and system for managing the relationships, that is, the 
links themselves, between digital assets of any type. 

10 ;2.PBSCyTOQN 0FT)HEmATBDART 

Conq)anies devote much timie and many resources to the creation, storage and retrieval of 
digital assets. In this patent, the term "digital assets" is intended to include assets of any type which 
have been digitized. Such assets could be, for exanq)le, logos, trademarks, marketing materials, press 
releases, newspeq)ers, publications of all types, print advertisements, internet advertismg, broadcast 

15 advertising, and so forth. Digital assets are therefore anything which can be digitized and which has 
value to a company in a stored electronic form. 

Even a noidsize company would probably require a large database management system in order 
to track, a typical number of objects. The problem increases exponentially with the number of objects in 
a database, and is therefore a much more serious issue for a company with a large database. 

20 Many of these objects are related. For example, consider an advertisement that includes several 

piece of animation, music and a logo. Each of these is a separate digital asset; each is related. In a 
database management system, containing a very large number of assets, it can be extremely difficult to 
manage not only the digital assets but also the multiple relationships between assets. 

If the company does store its digital assets, it is difficult to track and evaluate the currency of a 

25 particular digital asset. In other words, tracking whether a particular digital asset is still a valid version 
is difficult. In the past, digital assets and their relation to other digital assets, have been tracked 
manually if at all. Some semi-automated systems are known, in which an application may merely 
access one view of an asset. 

Certain versions of digital asset management have been attenq)ted for very limited applications. 

30 For exanq)le. Vignette Corp. offers a product under the tradema± IRM. This product manages 
relationships between web pages on a web site. Unfortunately, this product does not take into 
consideration objects of undefined depth. Moreover, it is geared to a particular application. 

Many conventionally available systems are content dependent. For exan:q)le, the QUARK^ 
desktop publishing software is content dependant. These types of inq)lementations are simply not 
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medium agnostic. Unfortunately, in the situation wheie the digital assets may include, streaming media, 
audio, video and/or text, the underlying content of the digital assets should not be relevant 

Other systems have attempted to track relationships between elements using a table. Consider, 
for exanq)le, U.S. Patent No.: 5,832,495, Gustman, in which relationships are tracked between elements 
5 by using a table. Unfortunately, the table quickly becomes very dense in relation to the number of links. 
As the number of elements increases, the size of the table becomes almost unmanageable. 

There thus remains a need for a system and method which can track relationships between 
digital assets, where the content of the digital asset itself is irrelevant. 

BRIEF SUMMARY OF THE INVENTION 

10 It is therefore an object of the present invention to provide a method and system for tracking 

digital assets in a maimer which can handle a large number of digital assets, and in a way in which the 
content and the asset is irrelevant. 

According to the invention, there is provided a method and system for digital asset link 
management. Electronic storage is accessed, the electronic storage containing at least one link relation, 

15 wherein each link relation includes a source identifier, a destination identifier, and a link type. It is 
determined, firom the source identifier and destination identifier, a corresponding source digital asset 
and a corresponding destination digital asset. The process of determining includes determining the 
relation type between the source digital asset and destination digital asset. There are provided many link 
relations, source digital assets, and destination digital assets. The source digital assets included in at 

20 least a portion of the link relations are destination digital assets in another portion of die link relations. 

Optionally, the source identifier and destination identifier each fiirther has a metadata type. It is 
determined, for the at least one link relation, one or more attributes corresponding to each metadata 
type* Optionally, the source digital asset and destination digital asset each farther includes a version 
indication. 

25 An initial identifier is provided, and the system searches (via traversal or browser) for the 

electronic storage for any link relation having one of a source identifier and destination identifier 
corresponding to the initial identifier. The link relation may be traversed to a next linked link relation, 
wherduDi one of the source identifier and destination identifier of the link relation corresponds 
respectively to one of the destination identifier and source identifier of the next linked link relation. 

30 Optionally, a bulk import is provided to create link relations, and the imported link relations are 

stored in the electronic storage. 

These and other objects, features and advantages of the present invention are readily apparent 
firom the following drawings and detailed description. 



35 



BRIEF DESCRIPTION OF THE DRAWINGS 

Hie invention is described in connection with the drawings: 
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FIG. 1 is a block diagram of the system for link management 
FIG. 2 illustrates a table of UOIs (units of information). 
FIG. 3 is an exemplary table of link types. 
FIG. 4 is an exemplary table of UOI links. 
5 FIG. 5 is an exemplary Metadata lookup table. 

FIG. 6 is an example state diagram illustrating a link life cycle. 

FIG. 7 is a block diagram illustrating the tool for visualization of a digital asset using the 
present system. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

10 The present invention seeks to solve the problems outlined above by tracking the link 

relationsiiip between digital assets, and giving the source and destination for each link much less 
relevance. Reference is made to Figure 1, The link asset management system includes inforaaation on 
UOIs 101, information on link types 103, and storage relating to the UOI links 105. Optionally included 
is an ancillary Metadata lookup 107. 

IS A "UOr* is a unit of information. It refers to an atomic unit of a digital asset, i.e., the smallest 

unit of information that has value, for example, a logo, text, etc. 

The UOIs 101 contains unique identifiers corresponding to digital assets, preferably stored as a 
table. The link types 103 is preferably stored as a table, in order to correlate link types to a description 
relation between assets, Exanq>les of link types include "toother of "container of 

20 The UOI links 105 contain link relations, i.e., corresponding sources, targets and 

links (or link types) between each conesponding source and target digital asset. 

The t^m "link" as used herein means a relation between two assets. A "link type" is intended 

to accommodate industry specific vocabulary; examples include: "a parent of ", "a 

container of ", "attorney of "• A "relationship" is an independent 

25 type of link, URL/URN or a hot spot Thus each 'link type" is a user defined relationship. 

The Metadata ("MD") lookup 107 is preferably provided, although it is not necessary. Every 
UOI in the UOIs 101 references Metadata assets (for example, file type, file format, other attributes, 
etc. about the data). The MD lookup 107 contains, by Metadata type, the expected attributes of each 
type of Metadata. These attributes include, for example, that a TIP bit file type has specific Metadata 

30 associated therewith. 

As is illustrated in Figure 1, a source value 109 and a destination value 111 are provided from 
the UOIs 101 to the UOI links 105. Also, die link type 113 is obtained from the link types file 103 and 
provided to the UOI links 105. Optionally, the source type and destination type 115, 117 are obtained 
from the Metadata lookup table 107. 

35 As is illustrated in Figure 2, the UOIs include information for each UOI on UOI identification 

201, and logical UOI identification 203. The UOIs also preferably includes version 205 and an 
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indication of whether this is Ae latest version 207. The UOI identification is a unique identifier 
corresponding to each unit of information. The logical UOI identification 203 is a logical identifier 
corresponding to the unit of information. In the example given in Figure 4, and referring to Figure 2 and 
3 the application program will determine that UOIb is a destination of UOIc and a source of UOIa. 

5 UOIa is determined to have the logical UOI identification of "Diagram", UOIb identification the logical 
UOI of "Chapter 1 ", and UOIc identification has a logical UOI identification of "Book". The link 
between UOIa and UOIb is ''TYPEa", i.e., "is container of. Thus, "Book" is he container of "Chapter 
1". The foregoing is given by way of example, of course, without limitation to specific link types and 
logical UOI identifications. Thus, the table minimally contains each unique UOI identification and each 

10 corresponding logical UOI identification, in order that the relatively short UOI identification can be 
stored and the logical UOI identification can be much longer. 

Also included in the UOIs 101, preferably, is an indication of the version 205 of each UOI. In 
this maimer, multiple versions can be simultaneously stored. Also, preferably there is an indication of 
whether that version is in fact the latest version 207. 

15 Thus, by searching the UOIs table by UOI identification, one can determine the corresponding 

logical UOI identification. 

Reference is now made to Figure 3, illustrating the link types 103. The link types includes each 
of the link type codes 301, and the corresponding link type names 303. Preferably, the link types 103 is 
in the form of a table. Hie link type code can be any appropriate code. The link type name preferably 

20 takes the format of "is of. The link type names are preferably determined by the user. 

By reference to the link ^es 103, one can determine the type of link between the two values. 

Optionally inchided information wiA each of the link types is an mdicator of whether the latest 
version is to be used, a reciprocal link type, any particular behavior, a status, and a description. The 
version connotes revisions of link participants. Hie reciprocal link type can best be understood by 

25 example. If, for example, the link type is "a parent of, the reciprocal link type is "a child of." The 
behavior is the semantic meaning associated with the specific link types. The status is a boolean 
description such as active versus inactive. The description describes the relationship between the UOI-s. 

Figure 4 illustrates the UOI links 105. The UOI links includes a source UOI 401, a destination 
UOI 403, and a link type 405. Preferably, the source UOI and the destination UOI are stored as UOI 

30 identifications, and the link types are stored as link type codes, in a table. The table supports multiple 
source UOIs corresponding to a single destination UOI and conversely multiple destination UOIs 
corresponding to a single source 205. In the UOI link table, preferably, each link is stored as a source 
identification and a destination identification with the link type. The schema is therefore generic in that 
it will support linking of two digital assets. Optional information stored in the UOIs also includes 

35 source type, destination type, sequence number, a flag to indicate use of the latest version, status, and 
status date. 
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An application program can access the UOI links based on either a source UOI or a destmation 
UOI. Based on the source (or destination) point, the application^ program may obtain all of the 
conesponding destinations (or sources) and determine the corresponding link types. Next, by referrace 
to the UOIs the source and destmation logical UOI identifications are obtained. Also, by accessing the 
5 link types, the link type name is determined. Given a particular source or destination, the application 
table can Uien traverse to each next source or destination UOI and/or logical UOI, and can indicate to 
the user the link type name. 

In the exanople given in Figure 4, and refeiring to Figure 2 and 3 the application program will 
determine that UOIb is a destination of UOIc and a source of UOIa. UOIa is determined to have the 
10 logical UOI identification of *l3ody.htm", UOIb identification the logical UOI of "charger.bmp", and 
UOIc identification has a logical UOI identification of "main.htm". The link between UOIa and UOIb is 
"TYPEa", i.e., "is cnnpAnetr of*. Thus, body.htm is the container of "charger.bmp". The foregoing is 
given by way of example, of course, without limitation to specific link types and logical UOI 
identifications. 

15 Figure 5 illustrates the Metadata lookup. The Metadata lookup 107 mcludes a Metadata type 

501 and corresponding Metadata attributes 503 for each Metadata type. Each Metadata type may have 
associated with it certain attributes. The attributes would be dependent upon the type of the 
Metadata. For example, if the Metadata type is a code for a GIF file, the attributes would be specific to 
GIF files. Typically, the attributes would include the name of the Metadata type (such as a file type), 

20 and category. Category is a taxonomy or classification hierarchy. 

The Metadata lookup is advantageously implemented as a table and is optionally included. It 
enhances the efficiency of the system to be able to reference a specific Metadata type and rapidly 
determine the expected attributes. Nevertheless, although the Metadata lookup table is preferred, it is 
ancillary and may be omitted. 

25 Figure 6 is a state table illustrating a life cycle of a link. At step 601, a link is created. 

Following creation, the link noay be traversed 603 by the application program. At least two types of 
traverse may be provided: searching 613 and browsing 611. The search traverse 613 permits a user to 
search for a specific source, destination or link type. The browse function 611 permits a user, whose 
application is presendy located at a particular link, source or destination to traverse the link forward or 

30 backward to linked sources and destinations. A link may also be updated 605. A link may be deleted 
607. Advantageously, deletion does not permanently remove the link. Thus, a link may be undeleted at 
609. Jn order to permanentiy delete a link, it is preferable to purge 615 the link. Providing a separate 
process for delete and purge permits deletions to occur and then be undeleted if in fact the deletions 
were not desired. 

35 In order to create a link, the link type should be defined by name, for example "is parent of\ or 

"is payment or. Permittuig a user to name ttie link types allows the creation of arbitrary relationships 
based on user defined terminology. If reciprocal relations are supported by the systen^ link creation is 
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an appropriate time to encourage the user to define the reciprocal relation, for exaiiq>le, '*is child of is 
the reciprocal relation to "is a parent of*. The user could add additional link types to the ongoing 
database. 

Once link types are created, a source and destination asset can be created. If the link types are 
5 created, they are added to the link type table 103. As source and destination assets are created, in 

connection with a particular relationship, the logical UOI identification, UOI identifications are added 

to the UOI; and the source UOI and the corresponding destination UOI and corresponding link types 

are added to the UOI link type table 105, 

Links may be traversed as follows: Reference is made to both Figure 6 and Figure 7, Figure 7 
10 illustrates a sliding window 703 and an exemplary portion of linked assets. Here, the linked assets 

include the current UOIs 701, the source UOIs at 705a, 705b, and the destination UOI 707a, 707b and 

707c. In the present example, the brochure 705a is a parent of the press release 701; and the web page 

705b is also the container of the press release 701. The press release itself is container of logo 707a, text 

707b. The press release 701 is also "source of ticker 707c. 
IS The sliding window 703 is currently located on a press release 701. The sliding window can be 

moved to anyone of the linked source objects or destination objects corresponding to the press release. 

When located on one of the source objects or destination objects, the sliding window would indicate for 

that UOI, all of its source and destination links. 

Reference is made back to Figure 6. The capability to update the UOIs is preferably provided. 
20 Update would permit the system to modify the relationships between UOIs. For exan^le, an existing 

link type between a source and a destination UOI could be replaced with a different link type. 

Alternatively, a source or destination UOI could be replaced with a chang^ UOI. 

The delete function illustrated in Figure 6, provides the capability to unlink the asset from the 

relationship. Note that the delete function does not delete the asset. 
25 The digital asset management life cycle is as follows. In ord^r to create UOIs, a system 

preferably has a preexisting list of the assets, and assigns to each of the assets a unique identification. 

Alternatively, assets may be created and added on the fly, and unique identifications added on the fly. 

As a first step, thus, UOIs are ingested, imported or loaded. As a second step, any ancillary Metadata is 

preferably created and the Metadata table is loaded. As a third step, each of the digital assets are 
30 assigned into the UOI table. As a forth, optional step, the assets are linked and placed into the UOI link 

table. As a fifth step, the currently linked assets may be searched and viewed, as discussed above in the 

link life cycle. 

Assets may also be linked during a bulk insert. To define a relation between any two assets, a 
link selection will be added within the UOIS tag off the XML input file, as show below: 



35 
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DTD modification: 
<!ELBMENT LINK EMPTY> 

<!ATrLIST UNK RELATION-TYPE CDATA #REQUIRED 

RELATED-ASSET ENTITY - or CDATA, dependent 

5 — on implementation. 

SGMUXML instance 
<UOIS . . . > 
<LINK 

RELATION-TYPE="is-brother-of' 
10 RELATED-ASSET="C:\joshua,gif" 
SEQUENCE^NUM="1" 
USE.LATEST^VERSION="N" 

/> 

The following are descriptions of prefeiied tags within the LINK tag: 
15 RELATION-TYPE: should match an existing NAME in the LINK-TYPES table 

RELATED-ASSET: one way to uniquely identify the destination asset to which the current 
asset will be linked. Jf this tag is used, the value should be a fully qualified path to the current location 
of the file. 

PO-REFERENCE: a second way to uniquely identify the destination asset to which the current 
20 asset will be linked. If this tag is used, the value should match the PO-REFERENCE value, in the 
UOIS section, of another asset in the same input file. 

ASSET-ID: a third way to uniquely identify the destination asset to which the current asset will 
be linked. This tag can be used to link assets being imported to assets in the repository. 

SEQUENCE-NUM: this optional tag may be used to provide a value, which will determine the 
25 position of the related assets among other destination assets of the same source asset and relation. If this 
tag is not used, no sequence is imposed on the destination assets. 

USE-LATEST VERSION: this optional tag may be used to indicate whether a hard or soft link 
should be created to the destination asset. If this tag is not used, a hard link will be created by default. 
This is equivalent to the tag having a value of N'. 
30 The following rules are advantageously used to guide the creation of relations between asset 

pairs during bulk import: 

Links may be created between pairs of assets created during the same bulk import job. Linking 
new assets to existing repository assets should not be supported through bulk import. 

Reciprocal relationships may be created automatically. If reciprocal relations are automatically 
35 created, tiiey should be created for all relations for which a reciprocal link type has been specified in the 
LINK-TYPES table via link administration. If there is no reciprocal link type (e.g., value is NULL), no 
reciprocal relation is created. If reciprocal relations are to be automatically created, Ms 
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functionality may still be provided by explicitly including the teciprocal LINK stanza in the import file. 
Reciprocal relations may then be defined on an as needed basis for each asset pair. 

There should be no limitation on the number of relations that may be defined via bulk import. 
There should be no limitation on the number of different link types that are used in defining 
5 relations via bulk import. That is, each asset pair may have a different link type from the others in the 
same file. In contrast, interactive import which preferably assumes the same link type for all asset pairs 
in the same import job. 

The foreign key constraints drawn between the UOLLINKS and the UOIs are optional as the 
source and destination assets need not be UOIs. 

10 The functionality of a "hard" or "soft" link if desired, may be represented in the data model by 

the USEJLATEST^VERSION information in the UOIs. A soft link is recorded with a value of Y' in 
this column. The default value is N'. There is interdependency with check-in when a link's destination 
is UOI and the USE^LATEST^VERSION column is Y*. When the version number for the 
corresponding logical UOIJDD is incremented and a new UOLID assigned to the new version on the 

IS UOIS table, the logic should be inq)lemented via a trigger. Giv^ that, product asseihbly will be able to 
use the DEST_VALUE directly and not have to determine the newest version. 

While the preferred mode and best mode for carrying out the invention have been described, 
those familiar with the art to which this invention relates will appreciate that various alternative designs 
and embodiments for practicing the invention are possible, and will fall within the scope of the 

20 following claims. 



i 
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What is claimed is: 

1 . A method for digital asset link managem^t, comprising the steps of 

(a) accessing electronic storage containing at least one link relation, wher^ each link 
relation includes a source identifier, a destination identifier, and a link type; and 
5 (b) determining, from the source identifier and destination identifier, a corresponding 

source digital asset and a corresponding destination digital asset. 

2. The method of claim 1, wherein the determining step fiirther includes determining the relation 
type between the source digital asset and destination digital asset. 

10 

3. The method of claim 1, wherein there are provided a plurality of link relations, a plurality of 
source digital assets, and a plurality of destination digital assets. 

4. Hie method of claim 1, wherein the source digital assets included in at least a portion of the 
1 5 link relations are destination digital assets in another portion of tiie link relations. 

5. The method of claim 1, wherein the source identifier and destination identifier each farther has 
a metadata Qrpe, and fiirther compri^g the step of determining, for the at least one link relation, a 
plurality of attributes corresponding to each nietadata type. 

20 

6. The method of claim 1, wherein the source digital asset and destination digital asset each 
fiirther includes a version indication. 

7. The method of claim 1, fiirther comprising the step of providing an initial identifier and 
25 searching the electronic storage for any link relation having one of a source identifier and destination 

identifier corresponding to the initial identifier. 

8. The method of claim 1, fiulher comprising the step of creating a second link relation and 
storing said second link relation in said electronic storage. 

30 

9. The method of claim 1, further comprising the step of traversmg at least one link relation to a 
next linked link relation, wherein one of the source identifier and destination identifier of the link 
relation corresponds respectively to one of the destination identifier and source identifier of the next 
linked link relation. 

35 

10. The method of claim 1, further comprising the step of performing a bulk import to create a 
plurality of Unk relations, and storing said imported link relations in said electronic storage. 
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11. A system for digital asset link management, comprising: 

(a) electronic storage containing at least one link relation, wherein each link relation 
includes a source identifi^, a destination identifier, and a link type; and 

(b) a plurality of digital assets, including, for each source identifier and each destination 
identifier, a corresponding source digital asset and a corresponding destination digital asset. 



12. The system of claim 11, wherein the link type corresponds to one of a plurality of relation types 
between the digital assets. 

10 13. The system of claim 11, wherein there are provided a plurality of link relations, a plurality of 
source digital assets, and a plurality of destination digital assets. 



14. The system of claim 11, wherem the source digital assets included in at least a portion of the 
link relations are destination digital assets in anofh^ portion of the link relations. 

15 

15. The system of claim 1 1, wherein the source identifier and destination identifier each further has 
a metadata type» each metadata type corresponding to a plurality of attributes. 

16. The system of claim 11, wherein the source digital asset and destination digital asset each 
20 further mcludes a version indication. 



17. The system of claim 11, further comprising a search routiine, responsive to an initial identifier, 
for searching the electronic storage for any link relation having one of a source identifier and 
destination identifi^ corresponding to the initial identifier. 

25 

18. The system of claim 11, further comprising means for creating a second link relation and 5 
storing said second link relation in said electronic storage. 

19. The system of claim 11, further comprising a browser, for traversing at least one link relation to 
30 a next linked link relation, wherein one of the source identifier and destination identifier of the link 

relation corresponds respectively to one of the destination identifier and source identifier of the next 
linked link relation. 

20. The system of claim 11, further comprising a means for a bulk in^ort to create a plurality of 
35 link relations, and to store said imported link relations in said electronic storage. 
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